The Secure Socket Layer (SSL) protocol (e.g., SSL Protocol Version 3.0) is presently the de facto industry standard for Web security. In fact, because most E-commerce applications are based on the Web, the SSL protocol is built into almost all Web servers and browsers, such as Netscape Enterprise Server, Microsoft Web Server, Netscape Communicator, and Microsoft Internet Explorer (IE).
The SSL protocol uses public key cryptography in conjunction with an X.509 certificate to provide server authentication and, optionally, client authentication. During the authentication process, the server sends its X.509 certificate chain which may or may not contain the root CA certificate who signed the server certificate to the client as part of the handshake messages the client and server exchange at the start of a session. The client validates the server's certificate through a normal certificate verification procedure if it has the server's certificate, it has the certification authority's (CA) certificate that signed the server's certificate, and it has associated trust information.
A common approach for providing the CA certificates and associated trust information to the client is to hard code a certificate database into the client software, such as done in Netscape Communicator and Microsoft IE. In this scheme, certificate management is up to the end users. For example, if a CA certificate is expired, it is the end users' responsibility to perform a new CA certificate rollover. Furthermore, the client hardware needs sufficient storage space to hold the certificate database, which usually ranges from 100 K to 400 k. This is typically not a problem in the personal computer environment.
However, the above approach can not be applied to mass market applications that run on the consumer appliances, such as set-top boxes, hand-held computers, pagers, and cell phones, due to at least any of the following reasons:                Public CA root certificates, as with substantially all certificates, expire and their lifetime may not fit nicely within the expected shelf-life or lifetime of a consumer product. Thus, a mechanism for securely updating CA root certificates is desirable.        In the unlikely event that a public CA's private root key is compromised, its root certificate must be revoked. Some trusted entity has to assume responsibility for revoking all compromised CA root certificates. In the personal computer environment, end users can revoke the root certificate by updating the client software if the compromised CA certificate is embedded in the client software. However, updating the software per each expired certificate is not practical in the consumer product environment because, e.g. it is practically impossible to recall all of the devices for participation in the update.        The typical consumer electronics user is unsophisticated with regard to security and, as such, cannot be expected to participate in the maintenance of the trust knowledge information base. In the consumer device environment, maintenance of the trust knowledge information base must occur transparently to the user and in a secure fashion.        Most consumer electronic devices have a limited amount of non-volatile flash memory where CA root certificates and associated trust information can be stored. It is important to minimize the usage of this memory space.        
Current Or Known Solutions
The SSL protocol itself does not specify how the root CA certificate validation should be implemented. Thus, such implementation is very much vendor dependent and proprietary to each vendor. There are very few publications regarding to this issue. Some well-known implementations are Netscape Communicator and Microsoft IE, which are based on a certificate database embedded in the browser software. In March 2001, an IETF draft, the Simple Certificate Validation Protocol (SCVP) regarding such certificate validation was published. The proposed protocol is based on a server that performs certificate validation.
The SCVP scheme uses a simple request-response model, which is briefly described as follows:
Upon receiving a certificate, the client sends a certificate validation request to a server. The request is optionally signed and contains the certificate in question and other parameters, such as extensions, as well as an answer that the client wants the server to provide. Based on the request, the server generates a response, signs it, and returns it to the client.
One advantage of the mechanism provided in this proposal is that it simplifies the client implementation for certificate validation, and it can be used as a general approach for clients to verify received certificates, including server certificates, in SSL. However, the protocol only addresses communications and does not address certificate management at the client endpoint. For example, it is important to provide a mechanism for delivering and updating root certificates that are needed to verify the server's responses, but such mechanism is not addressed in the proposal. The set of root certificates is the initial trust point for such protocol. Without an initial trust point, the certificate validation mechanism is still vulnerable.
Liberate Technologies of San Carlos, Calif. has developed a server-based certificate management mechanism that securely delivers root certificates and associated trust information to clients. With this scheme, the server certificates in SSL can be seamlessly validated. Such scheme fits particularly well into consumer devices and solves the problem of maintaining an initial trust point in the certificate chain, discussed above.
The Liberate mechanism works substantially as follows:
The building block of the scheme is the Root Security Information Object (RSIO), which is a data object that contains the following sets of information:
                A chain of Trusted Information Provider's (software provider, device owner, and Enhanced Service Provider (ESP)) Root Certificates. For the device owner and ESP, the chain only contains the most recent device owner/ESP root certificate.        A trust table consisting of a set of SHA-1 hash values of the trusted certificates. For each hash value in the table, there is a bit vector describing the operations for which the certificate is trusted, i.e. the trust vector, and a bit vector describing the operations which the certificate is trusted to delegate to other certificates. The table is digitally signed by the subject who provided the object.        A timestamp indicating the time this object is created.        The digital signature of the trust table.        
The Liberate mechanism typically involves three business entities, e.g. the software provider, a device owner, and an ESP, which forms a hierarchy with the software provider at the top, the device owner in the middle, and the ESP in the bottom. Each of the three entities provides an RSIO that is based on its own requirements. The root certificate of each entity must be submitted to, and verified by, the entity in the next higher level of the hierarchy and included in its RSIO. Thus, the RSIOs also form a hierarchy linked by their root certificates with the software provider RSIO at the top, the device owner RSIO in the middle, and the ESP RSIO at the bottom. Based on the RSIOs, the server constructs a Hierarchical Root Security Information Object (HRSIO) and delivers it to the client during the client boot up time.
The HRSIO contains the following information:                A chain of software provider Root Certificates.        A trust table signed by the most recent software provider Root Certificate.        One or more trust tables signed by trusted device owners and the device owner's Root Certificates.        A trust table signed by a trusted ESP and the ESP Root Certificate.        
The software provider root certificate is stored into the ROM of each client device during the manufacture process. Thus, upon receiving a HRSIO, the client can verify it through a chain of validation.
When a client attempts to initiate an SSL connection to a server, it proceeds through the phases of the SSL handshake. The discussion herein does not attempt to present the SSL protocol in detail, but rather highlights the points at which HRSIO information is used. In the initial phases of the handshake, the server presents its certificate and, optionally, the CA certificate that signed its certificate.
The proposed scheme has a significant advantage over the old scheme because of the following:                In the RSIO scheme, each hash value in the trust table is computed using the whole certificate information as the input. Consequently, having two certificates with different validity (a field contained in the certificate) results in two different hash values. This property creates an unnecessary failure in the SSL certificate chain validation in a common scenario:        
When the client receives a server certificate chain that contains the renewal of an expired root CA certificate and the client trust table only contains the old root CA certificate because the trust table has not been updated yet. In this case, the SSL certificate chain validation fails because the hashes of the two certificates do not match. That means, whenever a certificate expired in the RSIO, the corresponding RSIO provider has to update the certificate in its RSIO and reconstruct a new RSIO and deliver the updated trust table to the client. This actually needs to go through the whole RSIO update procedure.
However, it is a common practice to renew the CA certificate by extending the validity of the old certificate based on the same key pair if it has not been compromised. This practice is to minimize migration problems for the CAs. Thus, in this case, the RSIO update is unnecessary because the old certificate still should be treated as valid even it is expired because the old and the new certificate share the same key. This problem is perfectly solved in the proposed scheme by hashing the public key portion of the certificate during the creation of the trust table.
The client can then determine whether or not to continue the handshake by performing the following checks:                Verify that the certificate is valid at the current time.        Hash the server certificate, e.g. using SHA-1, and check to see if it is in the trust table. If so, the handshake can proceed if the trust vector indicates that the certificate is an SSL server certificate. If the hash is in the table, but the SSL server bit is not set in the trust vector, the handshake immediately fails. If the hash is not in the table, proceed to the next check.        If the CA's Root Certificate was not presented, retrieve it from the Security Service on the server.        Verify the digital signature on the server certificate, and verify that the signature came from the named CA using the CA's Root Certificate.        Hash the CA's Root Certificate, and check to see if it is in the trust table.        Verify that the table entry for the CA's Root Certificate is marked as trusted as a CA for issuing SSL server certificates.        
Once all these checks are complete, the client continues the SSL handshake by negotiating a cipher suite and exchanging keys with the server, and then begins transferring encrypted data.
Although the Liberate mechanism solves several problems, such approaches may have one or more of the following disadvantages:                There are too many dependencies on the software provider. A software company may not be qualified to behave as a CA and perform certificate management. For example, if the software provider's root certificate is compromised then the whole system may be vulnerable.        There is too much burden for the device owner and ESP. They must go through a series of steps to update their root certificates whenever their root certificates are expired or compromised. For example, the device owner must submit its new root certificate to the software provider and wait for a new RSIO that includes the new root certificate from the software provider. Then, the device owner must reconstruct a RSIO and deliver it to the ESP. The ESP must then reconstruct an RSO and deliver the updated information to the clients.        Such procedure is complicated. In the reality, the device owner and ESP are often the same party and, thus, the three-level hierarchy is redundant and creates overhead. Further, there are many human interactions involved whenever information in the RSIO must be updated. In such case, the turn around time may be too long.        
It would be advantageous to provide a simplified trust information delivery scheme for certificate validation.